Please consult the Extend manual for details about using ModL, the Extend programming language.
• Overview
This is the syntax definition and brief description of Extend's built-in modeling language ModL™, which is a structured subset of C with object-oriented extensions. The user types in the script which describes the parameters, initializations, and behavior of the block. Extend then checks, compiles, and saves the block when the block is closed. If there are any syntax errors in the script, the user is alerted to correct them. A script can be as simple as a single equation, or as sophisticated as an entire program.
Like C programs, a ModL script starts with type declarations and constant definitions. Because you declare these at the beginning of the script, before any message handlers or user-defined functions, they are considered static or permanent. They are therefore valid throughout the block’s script unless overridden by a local variable declaration.
After the type declarations, there are procedure and function definitions, and many message handlers. The procedures, functions, and message handlers are just definitions: they need to be called in order to be executed. Message handlers interpret messages that come from the simulation or from you. Extend runs the message handler whenever one of the messages is passed to the block.
In the examples below:
ModL keywords are in all CAPITALS, but ModL is case insensitive, and upper or lower case can be used interchangeably.
“id” means identifier (name) with optional dimensions (ie. array[2][3]).
“constant” is a number or string.
TYPE is one of the ModL variable types (below).
• Comments
start with 2 backslashes “//” or 2 asterisks “**” and end at the END of the current line.
• Names
Names for variables, constants, functions, and procedures can be up to 30 characters. Names can have letters, numbers, and the underscore (_) character; a name must begin with a letter. ModL is not case sensitive.
• Data Types
REAL or DOUBLE is a 20 significant figure IEEE floating point type (10 bytes of memory). The range of values is approximately ±1e±4900.
INTEGER or LONG is a 32 bit integer (4 bytes of memory). Maximum value is 2147483647; minimum value is -2147483648.
STRING or STR255 is 255 characters long (plus a length byte makes 256 bytes of memory). String literals (constants) are sequences of characters enclosed by quotes ("),
• Static and Local Variable Declarations and Definitions
Variables and constants must be declared before being used. Static and constant declarations are made at the beginning of a script and local declarations are made at the beginning of a message handler or user-declared function. The values of static variables are stored in the block even when the block is not open. Thus, they may be used to store data which must be preserved from one run of a simulation to the next. However, it is a good programming practice (and always safer) to initialize your variables in your scripts. Two advantages of using local variables are that they are not saved with the model and they do not use any of the block’s memory allocation. The disadvantages are that the values of local variables are not remembered after the message handler or function is left, and they can override static variables while the message handler is being executed.
• Type Declarations
The general forms of the type declarations are:
REAL id, id, ..... id; or DOUBLE id, id, ...... id;
INTEGER id, id, ..... id; or LONG id, id, ..... id;
In the constant definition, the type is implied by the format of the literal value. Constants are always static. ModL includes four predefined constants: BLANK, TRUE, FALSE, Pi.
• Type Conversions
Generally, ModL performs all type conversion automatically. Thus, integer values can be assigned to real variables, and mixed type arithmetic can be performed without explicity type conversion beforehand.
The hierarchy is STRING, REAL, INTEGER. That is, an operation between an INTEGER and REAL is converted to REAL, and an operation between any type and a STRING is converted to STRING. This allows statements such as STRING = STRING+number+STRING (very useful to send results to the user as Static or Edit Text items).
• Storage
You can use real, integer, or string arrays. Any array can have up to five dimensions, that is, up to five subscripts or indexes. Array sizes are limited to 2 billion elements. Arrays are accessed by “id[row][column]”.
Variables declared outside of a Message Handler or User-defined Function are static; they are saved over sessions with the model file. Maximum bytes of static variables is 32767 per script. If you need more, or don’t want huge files, use dynamic arrays, below.
Dynamic arrays are declared like Static variables, but with their first (leftmost) dimension value is missing. They are variable size, and can be assigned a size or resized using the makeArray function. The missing dimension number can be found by using the getDimension function. The storage that they use can be released using the disposeArray function. And they can be 200 million elements long and you can declare up to 254 dynamic arrays per block.
Temporary variables are declared inside of Message handlers or User-defined Functions. The maximum total bytes is 32767 per Function or Handler. They are released when the function returns to the caller, so don’t use them to store things you might need between function or message calls.
• System and Global Variables
ModL has some pre-defined variables that can be treated just like other static variables. There are also global variables which you can define yourself. See the System & Global Variables help topic.
• Operators
See the ModL Operators help topic.
• Statements
See the ModL Control Statements help topic.
• Functions and Message Handlers
Extend has many built-in functions and procedures, as listed in the ModL Functions help topics. You can also declare user-defined functions and procedures which are local to the block. Message Handlers are described in more detail in the ModL Message Handlers help topic.
Following is the syntax of how to declare user-defined functions and message handlers, and how to return from them.
// User-defined procedures have the following form:
PROCEDURE name (TYPE id, TYPE id,…, TYPE id)
{
optional local variable declarations
zero or more statements
}
// User-defined functions have the following form:
TYPE name (TYPE id, TYPE id,…, TYPE id)
{
optional local variable declarations
zero or more statements
return(value);
}
// User-defined function “forward” definition:
TYPE id (TYPE id, TYPE id,...., TYPE id) ; //note the semicolon
// Message handlers are declared as:
on MessageName // system or dialog message name
{
local variable declarations
zero or more statements;
}
The following statements are for returning from functions and message handlers:
RETURN(expression); // from TYPE functions
RETURN; // from message handlers or PROCEDURE
ABORT; // special return to abort the message. Used to prevent user dialog buttons from changing appearance, aborting the OK button dialog close, and to abort simulations.
• Connector Names and Their Use
Input and Output connectors can be used as Real variables or can have arrays passed to them during a simulation.
